home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 83 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.8 KB

  1. From: kanze@gabi.gabi-soft.fr (J. Kanze)
  2. Message-ID: <KANZE.96Jan22120854@gabi.gabi-soft.fr>
  3. X-Original-Date: 22 Jan 1996 11:08:54 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 22 Jan 96 13:38:45 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: STL still in standard
  9. Organization: GABI Software, Sarl.
  10. References: <4dd7on$djk@rc1.vub.ac.be> <4dgrb4$a2e@engnews1.Eng.Sun.COM>
  11.     <9601171106.AA12639@lts.sel.alcatel.de> <4du1v6$h74@jupiter.SJSU.EDU>
  12. In-Reply-To: horstman@jupiter.SJSU.EDU's message of 21 Jan 96 23:03:54 GMT
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMQOTpuEDnX0m9pzZAQESVwGAie57k0NkQGFf1ekiyMxkdYyr4xFBGqUP
  15.     b1XlP/yXYDRXUZxcu2gtTr+y4JY6hjdj
  16.     =dZlO
  17.  
  18. In article <4du1v6$h74@jupiter.SJSU.EDU> horstman@jupiter.SJSU.EDU (Cay
  19. S. Horstmann) writes:
  20.  
  21. > James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
  22. > >Safer implementations are possible; Cay Horstman, I think, has already
  23. > >made one available.  
  24. > Indeed. It works nicely as a debugging tool, and is 100% compatible
  25. > with plain STL. Think of it as an "assert" for STL. It is available
  26. > from http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html. A
  27. > number of people at NYU have ported it to g++. If there is interest,
  28. > I'll find out how far they got. 
  29.  
  30. Is it just for debugging.  I would imagine that one would be using this
  31. version most of the time, in preference to something more dangerous, and
  32. only abandon it when profiling showed that it was necessary.
  33.  
  34. > >Exception safe implementations are also possible.
  35. > >(It is also an open question how far one wants to go here.  I would
  36. > >accept, for example, that an exception from the comparison function
  37. > >when inserting into a map results in undefined behavior; if comparison
  38. > >can throw an exception, an STL map is perhaps not the appropriate
  39. > >container.)
  40. > I am not sure exceptions are the way to go--the great value of a
  41. > standard is that it is, well, standard. STL may not be the greatest
  42. > library on the planet, but it is certainly good enough, and it is
  43. > standard. I don't like the idea of tinkering with the interface by
  44. > adding exceptions.
  45.  
  46. Exceptions cannot be avoided.  If the behavior of STL is declared
  47. undefined if an object of the instantiation type throws an exception,
  48. for example, then it becomes practically unusable.  Most of my objects
  49. will acquire dynamic memory, and operator new may throw an exception.
  50.  
  51. This is not tinkering with the interface, this is a standards question:
  52. what is the defined behavior of, e.g.: vector< T > if T throws an
  53. exception?  What is the state of
  54.  
  55.     vector< T >            v( 5 ) ;
  56.  
  57. if the third call to T::T( T const& ) (to initialize v[ 2 ]) causes an
  58. exception to be thrown.
  59.  
  60. In the current (HP) implementation, v[ 0 ] and v[ 1 ] will have been
  61. fully constructed; v[ 2 ] presumably will have coped correctly to appear
  62. unconstructed, and v[ 3 ] and v[ 4 ] are just chunks of raw memory.
  63.  
  64. IMHO, for example, in the above case, it should be explicitly stated
  65. that the entire array is just raw memory.  (Note that because the
  66. exception propagates up out of the constructor of vector< T >, before
  67. the constructor has finished, the corresponding destructor will not be
  68. called.)  The user has *no* way of doing proper clean-up.
  69.  
  70. > My model here is the C string.h library. Consider strncpy. Could you
  71. > imagine a dumber function? If either of the arguments is null, it
  72. > dumps core. 99% of strncpy uses in my programs are of the form
  73. >     strncpy(buffer, s, sizeof(buffer));
  74. >     buffer[sizeof(buffer) - 1] = 0;
  75. > Sure, in 1% of the cases, I am glad it doesn't add the terminating 0,
  76. > but in 99% of the cases I hate it. But did I go out and write my own
  77. > superior replacement of strncpy? I did for a while and all of my team
  78. > members protested. They didn't want to learn my pet library. So I am
  79. > back to strncpy. Like Bjarne Stroustrup wrote, library design is
  80. > language design. 
  81. > Same with STL. I'd rather not figure out subtle differences between
  82. > customized STL versions, especially with something as subtle as
  83. > exception specifications. If it is a good idea for STL to throw
  84. > exceptions when the user inserts something stupid, then let's lobby to
  85. > make that a part of the standard. Otherwise put the test in the user
  86. > code, not into a custom STL.
  87.  
  88. I agree.  The present situation is that there is one aspect of the
  89. interface definition which has not been defined.  In order to be useful,
  90. it must be.
  91. -- 
  92. James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
  93. GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
  94. Conseils, itudes et rialisations en logiciel orienti objet --
  95.               -- A la recherche d'une activiti dans une region francophone
  96. ---
  97. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  98.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  99.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  100.